%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%				CONFIGURAZIONE DEL DOCUMENTO (NON MODIFICARE)			%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass[a4paper,11ptn]{report}                                   %
\usepackage[italian]{babel}                                             %
\usepackage{graphicx}                                                   %
\usepackage[colorlinks=true]{hyperref}                                  %
\usepackage{url}                                                        %
\usepackage{eurosym}                                                    %
\usepackage{lastpage}                                                   %
\usepackage{fancyhdr}                                                   %
\usepackage[utf8]{inputenc}                                             %
\hypersetup{linkbordercolor=1 1 1}                                      %
\hypersetup{urlcolor=blue}                                              %
\hypersetup{linkcolor=black}                                            %
\graphicspath{{../immagini/}}                                           %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 		COMPLETARE I CAMPI VUOTI PER LA GENERAZIONE AUTOMATICA			%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newcommand{\Documento}{Piano di Qualifica}                             % nome del documento
\newcommand{\Sommario}{
Lo scopo del presente documento \`e quello di informare il committente riguardo le strategie di validazione e verifica che la SevenSoft applicher\`a al prodotto \textit{SiFiSy.}}    % sommario
\newcommand{\CodiceRevisione}{RPP}                                      % revisione (es. RPP)
\newcommand{\DataCreazione}{29 Novembre 2009}                           % data di creazione
\newcommand{\Versione}{2.0}                                             % versione attuale
\newcommand{\StatoDocumento}{Formale, Esterno}                          % stato (es. Formale, Interno)
\newcommand{\Redazione}{Luca Zanini}                                    % autore del documento
\newcommand{\Revisione}{Giuseppe Biolo}                                 % verificatore del documento
\newcommand{\Approvazione}{Giuseppe Ferri}                              % chi approva (responsabile)
\newcommand{\Committente}{Prof. Tullio Vardanega, Prof. Renato Conte}   % committente/i
\newcommand{\Proponente}{Dott. Claudio Palazzi}                         % proponente/i
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 			IMPOSTAZIONE DEL DOCUMENTO (NON MODIFICARE)					%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\fancypagestyle{plain}{                                                 %
\fancyhf{}                                                              %
\fancyhead[L]{\Documento - \CodiceRevisione}                            %
\fancyfoot[C]{\thepage}                                                 %
\fancyhead[R]{\includegraphics[scale=0.3]{logoSevenSoft.png}}           %
}                                                                       %
\begin{document}                                                        %
\pagenumbering{Roman}                                                   %
\begin{center}                                                          %
\includegraphics[scale=0.8]{logoSevenSoft.png}\\                        %
\vspace*{1in}                                                           %
\huge{\textbf{\textbf{\Documento}}}\\                                   %
\vspace*{2cm}                                                           %
Versione: \Versione\\                                                   %
\vspace*{3cm}                                                           %
\vspace*{0.5in}                                                         %
\textbf{Sommario}\\                                                     %
\end{center}                                                            %
\begin{normalsize}                                                      %
\Sommario                                                               %
\end{normalsize}                                                        %
\newpage                                                                %
\thispagestyle{plain}                                                   %
\vspace*{0.5in}                                                         %
\begin{center}                                                          %
\begin{tabular}{l}                                                      %
\Large{\textbf{Capitolato: Simulatore File System}}\\                   %
\begin{tabular}{|p{5cm}|p{7cm}|}                                        %
\hline                                                                  %
\textbf{Data creazione:} & \DataCreazione\\                             %
\hline                                                                  %
\textbf{Versione:} & \Versione\\                                        %
\hline                                                                  %
\textbf{Stato del documento:} & \StatoDocumento\\                       %
\hline                                                                  %
\textbf{Redazione:} & \Redazione\\                                      %
\hline                                                                  %
\textbf{Revisione:} & \Revisione \\                                     %
\hline                                                                  %
\textbf{Approvazione:}  & \Approvazione\\                               %
\hline                                                                  %
\textbf{Committente:} & \Committente \\                                 %
\hline                                                                  %
\textbf{Proponente:} & \Proponente \\                                   %
\hline                                                                  %
\end{tabular}\\                                                         %
\end{tabular}                                                           %
\end{center}                                                            %
\vspace*{2cm}                                                           %
\begin{center}                                                          %
\begin{tabular}{l}                                                      %
\Large{\textbf{Diario delle modifiche}}\\                               %
\begin{tabular}{|p{1.5cm}|p{3cm}|p{7.5cm}|}                             %
\hline                                                                  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 		COMPLETARE I CAMPI VUOTI PER IL DIARIO DELLE MODIFICHE			%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\textbf{Versione} & \textbf{Data rilascio} & \textbf{Descrizione} \\	%
\hline
2.0 & 22 Gennaio 2010 & Ulteriore integrazione del contenuto e correzioni\\
\hline
1.1 & 20 Gennaio 2010 & Rivedute e incrementate alcune sezioni\\
\hline
1.0 & 15 Gennaio 2010 & Correzione errori ortografici e approfondimento di alcune sezioni\\
\hline
0.4 & 08 Dicembre 2009 & Addattamento a modello unico e completamento documento\\
\hline
0.4 & 08 Dicembre 2009 & Addattamento a modello unico e completamento documento\\
\hline
0.3 & 06 Dicembre 2009 & Correzioni ortografiche varie\\
\hline
0.2 & 30 Novembre 2009 & Integrazione con punti successivi e correzioni\\
\hline
0.1 & 29 Novembre 2009 & Prima stesura documento\\
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 			IMPOSTAZIONE DEL DOCUMENTO (NON MODIFICARE)					%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\hline                                                                  %
\end{tabular} \\                                                        %
\end{tabular}                                                           %
\end{center}                                                            %
\newpage                                                                %
\tableofcontents                                                        %
\newpage                                                                %
\pagenumbering{arabic}                                                  %
\fancypagestyle{plain}{                                                 %
\fancyhf{}                                                              %
\fancyhead[L]{\Documento - \CodiceRevisione}                            %
\fancyfoot[C]{\thepage\ di \pageref{LastPage}}                          %
\fancyhead[R]{\includegraphics[scale=0.3]{logoSevenSoft.png}}           %
}                                                                       %
\pagestyle{plain}                                                       %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%	COMPLETARE I CAMPI VUOTI PER IL TESTO DEL DOCUMENTO (VEDI NORME)	%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Capitolo 1 - INTRODUZIONE AL DOCUMENTO
\chapter{Introduzione}

\section{Scopo del documento}
Il presente documento si propone di fornire definizioni e strategie di pianificazione delle procedure che il team SevenSoft adotter\`a per garantire la qualit\`a del prodotto denominato SiFiSy.\\
Il Piano di Qualifica \`e il prodotto dell'attivit\`a di Verifica e Validazione che SevenSoft ha intenzione di mettere in atto come descritto nello standard ISO/IEC 12207:1995. Tali attivit\`a verranno applicate a tutti i processi di ciclo di vita del prodotto software. Il Piano di Qualifica verr\`a aggiornato regolarmente durante tutte le fasi di sviluppo, in modo da adeguarsi alle scelte progettuali, ad eventuali variazioni dei requisiti e/o richieste in fase di revisione da parte del committente.\\
Per garantire un adeguato livello qualitativo \`e necessario il rispetto delle specifiche definite in fase di analisi di progetto.\\
La versione iniziale di questo documento ha valore contrattuale per la gara d'appalto; il documento verr\`a di seguito incrementato (ad es. includendo gli eventuali test) e le prossime versioni avranno valore contrattuale solo dopo l'approvazione del committente.

\section{Scopo del prodotto}
SiFiSy \`e  un simulatore di \underline{FS} che ha come obiettivo quello di mostrare agli studenti, ma in generale a qualunque utente interessato, il funzionamento e la logica di implementazione di diversi \underline{FS}, con la possibilit\`a  di confrontare le varie configurazioni scelte e condurre alcune analisi significative.\\
Per ulteriori informazioni riguardanti scopi e funzionalit\`a del prodotto si prega di fare riferimento al documento ''Analisi dei Requisiti''.

\section{Glossario}
Il glossario viene fornito in un documento separato denominato ''Glossario'' che raccoglie le definizioni, acronimi ed abbreviazioni di tutta la documentazione. I termini presenti nel glossario verranno marcati nel documento con una sottolineatura.

\section{Riferimenti}
\subsection{Riferimenti normativi}
\begin{itemize}
\item{Std IEEE 1008-1987 - Standard for Software Unit Testing}
\item{Std AS/NZS ISO/IEC 12207:1997 Software life cycle processes}
\item{normeDiProgetto-2.1.pdf}
\end{itemize}
\subsection{Riferimenti informativi}
\begin{itemize}
\item {Ian Sommerville, Software Engineering, Addison Wesley, 8a edizione (04 Giugno 2006).\\
	ISBN: 978-0321313799}
\item {Guide to the SWEBOK:\\
\url{http://www.swebok.org}}
\item {Assembla Home Page\\
\url{http://www.assembla.com}}
\item {Subversion \\
\url{http://subversion.tigris.org}}
\end{itemize}

% Capitolo 2 - VISIONE GENERALE DELLA STRATEGIA DI VERIFICA
\chapter{Visione generale della strategia di verifica}

\section{Organizzazione, pianificazione strategica e temporale, responsabilit\`a}
Le responsabilit\`a verso il cliente sulle attivit\`a di verifica sono a carico del Responsabile di progetto.\\
Durante la realizzazione del prodotto, il responsabile interno dell'attivit\`a di verifica \`e il Verificatore. In particolare, viene nominato un responsabile tra tutti i Verificatori attivi durante la fase, con il compito di coordinare le verifiche e di redigere un resoconto riassuntivo dei test eseguiti. Tali resoconti saranno allegati al presente documento nell'apposita sezione e saranno necessari al Responsabile di progetto per verificare la copertura dei test.\\
La natura del modello a cascata, scelto da SevenSoft per lo sviluppo del progetto, impone alcune regole e strategie di verifica che verranno qui di seguito descritte.\\
Le attivit\`a di verifica cominciano approssimativamente in un periodo compreso tra l'inizio e la met\`a di una fase o appena esiste un prodotto organizzato, su cui quindi abbia senso fare qualsiasi tipo di verifica.\\
Le attivit\`a di verifica sono pianificate in base alle varie fasi di realizzazione del progetto e sono elencate di seguito.
\subsection{Fase di analisi dei requisiti}
Durante la fase di analisi dei requisiti, l'attivit\`a di verifica inizia nel momento in cui gli Analisti presentano una prima stesura del documento, contenente i requisiti pi\`u immediati definiti con una prima analisi del capitolato.\\
Il lavoro dei Verificatori consiste nel controllare tale documento e nel comunicare agli Analisti se vi sono errori tipografici e dattilografici; inoltre dovranno assicurarsi che il contenuto del documento e delle rispettive sezioni siano coerenti con l'argomento trattato e verificare che non siano presenti requisiti ridondanti, superflui o in conflitto tra di loro.\\
Nel caso fossero presenti errori nella stesura dei requisiti il lavoro degli Analisti potrebbe quindi ripetersi finch\`e il processo di verifica non avr\`a esito positivo. Il processo di analisi e quello di verifica procedono quindi con un certo grado di parallelismo.\\
Una volta terminato il lavoro degli Analisti, il documento finale sar\`a revisionato dai Verificatori e, se approvato dal Responsabile di progetto, sar\`a  consegnato al proponente per permettergli di valutare l'offerta della SevenSoft riguardo al prodotto richiesto.\\
Il contenuto del documento sar\`a in parte negoziabile col proponente, ovvero eventuali requisiti aggiuntivi, provenienti dal proponente stesso o dal fornitore, saranno oggetto di analisi per verificarne la fattibilit\`a. In questo modo, se l'offerta venisse accettata, il lavoro degli Analisti, e di conseguenza quello dei Verificatori, potrebbe ancora ripetersi per la definizione dei nuovi requisiti che eventualmente dovessero emergere dalla discussione con il proponente e per la verifica della documentazione annessa.\\
Le attivit\`a di verifica in questa prima fase saranno principalmente rivolte alla correttezza della forma e dei contenuti del documento di Analisi dei Requisiti.\\
\subsection{Fase di progettazione}
Durante la fase di progettazione, saranno eseguite principalmente due fasi di verifica:
\begin{itemize}
\item Al termine della progettazione architetturale \`e compito dei Verificatori stabilire se la progettazione fatta soddisfa i requisiti attesi dal committente (prova di copertura);
\item L'accettazione della progettazione architetturale d\`a il via ai Progettisti per cominciare il processo di progettazione di dettaglio, che dovr\`a essere fedele alla progettazione architetturale approvata.\\
In questa seconda fase il lavoro di Verificatori e Progettisti pu\`o, ancora una volta, procedere con un certo grado di parallelismo, attivando il processo di verifica ogni qualvolta sia necessario valutare la correttezza del risultato di un processo di progettazione.\\
Cos\`i facendo sar\`a pi\`u facile garantire la correttezza di ogni singola parte progettata e alla fine baster\`a controllare che l'aggregazione di tutte le parti, precedentemente controllate e approvate, non sia fonte di errore.
\end{itemize}
\subsection{Fase di realizzazione}
Alla fine della fase di realizzazione saranno eseguiti test dinamici:
\begin{itemize}
\item Questi test di verifica avranno il compito di dimostrare l'affidabilit\`a e il funzionamento corretto del prodotto.
\item I test saranno eseguiti inizialmente sulle singole unit\`a del prodotto (test di unit\`a), poi sull'aggregazione di pi\`u unit\`a fra loro (test di integrazione) e infine sul prodotto nel suo insieme (test di sistema).\\
Per eseguire i test si utilizzeranno degli strumenti di \underline{benchmark} appropriati in modo da facilitare una misurazione accurata e attendibile delle performance del sistema.
\end{itemize}

\section{Risorse necessarie, risorse disponibili}
Le risorse umane necessarie per eseguire l'attivit\`a di verifica possono variare nel corso delle fasi di sviluppo del progetto in base alla difficolt\`a del processo in corso.\\
Per tutta la durata del progetto i membri del gruppo lavoreranno seguendo le regole prefissate presenti nel documento interno ''Norme di Progetto''.\\
Per tutta la durata del ciclo di vita del progetto \`e compito dell'Amministratore coordinare l'utilizzo delle risorse necessarie alla sua realizzazione.\\
In particolare si prester\`a attenzione per garantire che l'uso delle risorse disponibili sia efficiente per ottenere un adeguato livello di verifica.\\
Per la comunicazione tra i componenti \`e stato creato un account Assembla raggiungibile all'URL: \url{http://www.assembla.com/flows/flow/adg2l2s}. Essendo inoltre ogni componente provvisto di un account Gmail, verr\`a utilizzato il sistema di chat locale per la comunicazione interattiva. Per l'archiviazione dei file verr\`a invece utilizzato un server \underline{Subversion}.

\section{Strumenti, tecniche, metodi}
L'attivit\`a di verifica \`e volta a migliorare la qualit\`a dei processi necessari al corretto sviluppo del prodotto; per garantire ci\`o il prodotto e i processi istanziati saranno costantemente sottoposti a questa attivit\`a.\\
La verifica verr\`a divisa in due fasi:
\subsection{Analisi Statica}
Questa fase verr\`a effettuata durante la stesura del codice sorgente per rilevare errori, omissioni o incongruenze che possono sorgere tra il progetto e i requisiti; questo tipo di analisi sar\`a quindi applicato sulla struttura delle varie componenti del progetto.\\
L'analisi statica comprende le seguenti sottofasi di verifica:
\begin{itemize}
\item Analisi del flusso di controllo per accertare la corretta esecuzione del codice; si verificher\`a in particolare che non siano presenti istruzioni la cui condizione di accesso non pu\`o mai essere vera (irraggiungibili);
\item Analisi del flusso dei dati per accertare la corretta inizializzazione dei campi dati e delle variabili nelle istanze dei vari oggetti che compongono il software;
\item Verifica formale del codice per constatare la correttezza di ogni unit\`a, in modo che la successiva aggregazione delle singole parti produca i risultati attesi.
\end{itemize}

\subsection{Analisi Dinamica}
Questa fase prevede la prova di utilizzo del prodotto durante la sua progettazione e al completamento della sua realizzazione per quanto riguarda tutte le sue funzionalit\`a, man mano che queste verranno aggiunte.\\
Gli strumenti per svolgere i test saranno elencati e descritti in questo documento nel momento in cui il gruppo si trover\`a nella necessit\`a di svolgere questo tipo di analisi, quindi indicativamente, come descritto sopra, da quando sar\`a attiva la fase di progettazione.

% Capitolo 3 - GESTIONE AMMINISTRATIVA DELLA REVISIONE
\chapter{Gestione amministrativa della revisione}

\section{Anomalie e discrepanze}
Per la gestione di errori durante la realizzazione del prodotto, discostamenti dalle attese e risultati non previsti, il gruppo SevenSoft si \`e imposto di gestire in maniera controllata anomalie e discrepanze, di cui segue la definizione:
\begin{itemize}
\item Anomalie: sono usate per rappresentare errori nel prodotto finale o in uno semifinale; in genere le anomalie impediscono il corretto funzionamento di un prodotto e la sua stabilit\`a nell'utilizzo;
\item Discrepanze: sono usate per rappresentare discostamenti dalle attese che il committente o lo stesso gruppo SevenSoft hanno nei confronti del prodotto finale o di uno semifinale; in genere una discrepanza non compromette il funzionamento del prodotto. La corretta stesura e comprensione dei requisiti dovrebbe essere sufficiente a ridurre significativamente il numero di discrepanze presenti in un prodotto.
\end{itemize}
\section{Modalit\`a di comunicazione}
Per garantire una comunicazione organizzata di anomalie e discrepanze si \`e scelto di assegnare un \underline{ticket} ad ogni prodotto del lavoro del gruppo, la cui gestione \`e automatizzata da \underline{Assembla}, il sito di appoggio per la realizzazione del progetto.\\
Ogni qualvolta sia completato un \underline{ticket} assegnato ad un prodotto, dovr\`a esserci un corrispondente \underline{ticket} che richieda la verifica del prodotto stesso. Il nuovo \underline{ticket} verr\`a assegnato al responsabile tra i Verificatori attivi, il quale avr\`a il compito di completare la verifica richiesta o, eventualmente, inoltrarlo ad un suo sottoposto.\\
In questo modo si cerca di ottimizzare il tempo necessario alla segnalazione e risoluzione di anomalie e discrepanze del prodotto durante lo sviluppo; inoltre \`e cos\`i possibile tenere traccia di queste, con data di apertura e chiusura di ogni \underline{ticket}.
\subsection{Trattamento delle anomalie}
Eventuali anomalie riscontrate prima della consegna del prodotto al committente sono sotto la responsabilit\`a del gruppo SevenSoft, il quale si impegna a risolverle.\\
Le comunicazioni di anomalie devono contenere le seguenti informazioni:
\begin{itemize}
\item Nominativo del Verificatore o di chi ha riscontrato l'anomalia;
\item Data di creazione;
\item Natura dell'anomalia;
\item Piccola descrizione dello scenario e delle condizioni sotto le quali si \`e verificata l'anomalia.
\end{itemize}
Alla ricezione di una comunicazione di anomalia il Responsabile:
\begin{itemize}
\item Valuta la criticit\`a dell'anomalia indicando (se possibile) il requisito al quale essa \`e associata (cap. 4 del documento ''Analisi dei Requisiti'').
\item Incarica il responsabile tra i Verificatori attivi (in accordo con quanto definito nel Piano di Progetto) per svolgere test sull'anomalia:
\subitem Se dagli accertamenti del Verificatore risulta che l'anomalia \`e banale (ad es. una correzione ortografica in un documento) pu\`o essere risolta direttamente dal Verificatore;
\subitem Se dagli accertamenti del Verificatore risulta che l'errore non esiste, allora il Responsabile avverte chi ha sollevato la comunicazione che la gestione dell'anomalia \`e terminata;
\subitem Se dagli accertamenti del Verificatore risulta che l'errore esiste, la gestione dell'anomalia continua passando ad una seconda fase.
\end{itemize}
La seconda fase per la gestione dell'anomalia continua coinvolgendo il personale addetto alla realizzazione del prodotto intermedio soggetto all'anomalia, allo scopo di valutare la soluzione.\\
Per fare ci\`o il Responsabile, una volta ricevuta la segnalazione, aprir\`a un \underline{ticket} indirizzato all'autore del prodotto testato.\\
Se la soluzione migliore del problema non risulta vantaggiosa in termine di tempo e costi per il committente, o le soluzioni possibili sono tutte in contrasto con il modello di vita del prodotto (sequenziale), viene terminata la gestione dell'anomalia tenendo traccia dell'anomalia irrisolta in un documento che sar\`a corredo del prodotto consegnato. In caso contrario viene eseguita la correzione.\\
Una volta completata la correzione dell'anomalia, il \underline{ticket} corrispondente potr\`a essere chiuso.\\
Questa procedura di controllo e risoluzione sar\`a ripetuta finch\`e il Verificatore non notificher\`a pi\`u anomalie nei suoi test.\\
SevenSoft si impegna comunque a consegnare al committente un prodotto, per quanto possibile, privo di anomalie.

\subsection{Trattamento delle discrepanze}
Qualora le attivit\`a di verifica e validazione provassero l'esistenza di discrepanze in un prodotto semifinale, queste dovranno essere trattate con una procedura simile a quella della gestione delle anomalie (vedi quanto detto sopra).\\
SevenSoft dedicher\`a molto impegno perch\`e le dissonanze vengano portate ad assonanze, in modo che il prodotto finale sia quanto pi\`u possibile adeguato alle aspettative del committente.\\
Qualora la procedura di trattamento delle discrepanze (dallo studio alla attuazione della soluzione) risultasse inaccettabile in termini di tempo e costi per il committente o si presentasse come una situazione di elevato rischio di fallimento del progetto, la discrepanza non verr\`a risolta o verr\`a risolta solo in parte (secondo accordi che vengono presi con il committente stesso in questa situazione).\\
Di ogni discrepanza devono essere documentate alcune caratteristiche:
\begin{itemize}
\item Responsabile/i della discrepanza (se individuabile);
\item Requisito non soddisfatto;
\item Criticit\`a (se la discrepanza \`e totale o parziale);
\item Risorse necessarie per la soluzione (costi, strumenti, ecc.).
\end{itemize}
La procedura di trattamento delle discrepanze, dopo l'apertura del corrispondente \underline{ticket}, \`e equivalente a quella di trattamento delle anomalie.

\section{Procedure di controllo di qualit\`a di processo}
Il controllo della qualit\`a del software interessa l'intero processo di sviluppo del prodotto in questione. A tale scopo sono stati adottati degli standard di documentazione che regolano la struttura e la presentazione dei documenti, nonch\`e degli standard di processo. Quest'ultimi definiscono i processi da seguire durante tutto lo sviluppo software; essi includono definizione dei processi di specifica, progettazione e convalida, oltre ad una descrizione dei documenti che dovrebbero essere scritti durante l'esecuzione di questi processi.\\
Il controllo di qualit\`a prevede il monitoraggio del processo software, per garantire che le procedure e gli standard di qualit\`a siano seguiti. Esso comprende inoltre il miglioramento del processo e la soluzione degli eventuali problemi. Quest'ultimo consiste nel comprendere i processi esistenti e modificarli per aumentare la qualit\`a del software e/o diminuire i costi ed i tempi di sviluppo. Il suo obiettivo principale \`e quello di concentrarsi sul perfezionamento, per migliorare la qualit\`a del prodotto ed in particolare per ridurre il numero di difetti nel software consegnato. Una volta ottenuto ci\`o, gli obiettivi primari diventeranno la riduzione dei costi e dei tempi.\\
Per avere un esteso controllo degli errori, le modifiche apportate ai documenti, in seguito a inconsistenze riscontrate durante la fase di verifica e stesura, verranno notificate secondo alcune convenzioni interne illustrate nel documento ''Norme Di Progetto''. Queste modifiche si troveranno all'inizio di ogni documento nella sezione ''Diario delle modifiche''. I verificatori sono tenuti a controllare parallelamente la documentazione sul lavoro svolto.\\
Molta attenzione di SevenSoft, in questo progetto, \`e focalizzata sull'incremento della qualit\`a dei processi durante la realizzazione del prodotto.\\
Questo intento \`e realizzato gestendo i processi con la tecnica \underline{PDCA} che li rende misurabili, riproducibili e di pi\`u facile verifica. Durante i colloqui interni si parler\`a di qualit\`a del processo, e si tenter\`a di stabilire dei parametri per quantificarla e, possibilmente, migliorarla.\\
La misurazione della qualit\`a di processo avviene:
\begin{itemize}
\item Definendo il processo, specificandone i proprietari, i requisiti e la criticit\`a (gravit\`a delle conseguenze se il processo contiene errori);
\item Esaminando l'output del prodotto, verificando quindi che il prodotto del processo abbia le qualit\`a e caratteristiche attese.
\end{itemize}
Per fare ci\`o \`e necessario innanzitutto definire quali sono le caratteristiche di qualit\`a del processo, per poi eseguire un'attivit\`a di verifica documentata per vedere se tali caratteristiche sono soddisfatte.\\
Da questi parametri \`e possibile avere una misura per decidere se le risorse messe a disposizione del processo erano maggiori o minori di quelle necessarie e, nel caso che il prodotto del processo non avesse le caratteristiche di qualit\`a aspettate, si avranno dei parametri per valutare l'onere dovuto al miglioramento del prodotto del processo (in termini di tempo, risorse e costo).\\
L'Amministratore ha il compito di redigere delle norme per far s\`i che il prodotto del processo sia facilmente analizzabile e verificabile (strutturato, predicibile, modulare, chiaro e non ambiguo nei contenuti).

% Capitolo 4 - RESOCONTO DELLE ATTIVITA DI VERIFICA
\chapter{Resoconto delle attivit\`a di verifica}

\section{Tracciamento componenti-requisiti}
Per una completa e chiara tracciabilit\`a componenti-requisiti, ogni componente, classe o metodo del prodotto SiFiSy \`e stato ideato come risposta ad ogni singolo requisito. Al fine di tenere traccia di tali corrispondenze \`e stata redatta una tabella, consultabile nel documento ''Specifica Tecnica'', che identifica per ogni componente quali sono i requisiti che la interessano. Ci\`o faciliter\`a la fase di verifica; si attester\`a quindi se ogni componente soddisfi pienamente i requisiti ad esso associato.

\section{Dettaglio dell'esito delle revisioni}
\subsection{RR - Revisione dei requisiti}
Documentazione per la Revisione dei Requisiti: segnalati alcuni errori di tipografia e ortografia corretti celermente dai rispettivi redattori. Lacune o errori sulla stesura di alcune sezioni dei documenti come riferimenti bibliografici troppo generici o utilizzo scorretto dei nomi.\\
I documenti da rivedere e correggere in maniera approfondita sono soprattutto quello di Analasi dei Requisiti, Norme di Progetto e Piano di Qualifica.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%				FINE DEL DOCUMENTO (NON MODIFICARE)						%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}															%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 